On doing geometry in CAYLEY

These notes were produced in response to a question from John Cannon: what issues are involved in adding facilities to CAYLEY for doing finite geometry? More specifically, what facilities would geometers want? At first sight, the idea of geometry in CAYLEY seems very natural. Groups and geometry have been intimately linked since long before the time of Klein. Many of the groups with which CAYLEY users deal act naturally on geometries. An important point which I’ll touch on briefly later is this: if we’re given a group which happens to be a classical group, many algorithmic questions (e.g. finding particular kinds of subgroups) become much easier once we’ve found and coordinatised the geometry on which the group acts. With further thought, however, we see how opposed in spirit the two areas are. Everyone agrees on what a group is. Moreover, there are only a few ways in which a group is likely to be presented, and CAYLEY has facilities to deal with each of these. In each case, these are basic algorithms of such subtlety as to deter the casual user from implementing them – surely one of the facts that called CAYLEY into being in the first place. On the other hand, the sheer variety of finite geometries daunts the beginner, who meets projective, affine and polar spaces, buildings, generalised polygons, (semi) partial geometries, t-designs, Steiner systems, Latin squares, nets, codes, matroids, permutation geometries, to name just a few. The range of questions asked about them is even more bewildering. Not surprisingly, there are few algorithms of comparable sophistication to the meataxe, Todd–Coxeter, or Knuth– Bendix. If you want to find something, you probably have to do an exhaustive search, with backtracking, and expect to have to wait a long time for the result. Fortunately, the system designer doesn’t have to know all the different axiom systems. The computer must hold a representation of the object, but doesn’t have